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ETSI 



(3G TS 23.041 version 3.1 .0 Release 1999) 3 eTSI TS 123 041 V3.1 .0 (2000-01) 



Contents 

Foreword 5 

1 Scope 6 

1.1 Normative references 6 

1.2 Abbreviations 7 

2 General description 7 

3 Network Architecture 7 

3.1 GSM Network Architecture 8 

3.2 UMTS Network Architecture 8 

4 CBE Functionality 9 

5 CBC Functionality 9 

6 BSC/RNC Functionality 9 

7 BTS Functionality 10 

8 MS/UE Functionality 10 

9 Protocols and Protocol Architecture 11 

9.1 Requirements on the Radio Access Network 11 

9.1.1 GSM Radio Access Network 11 

9.1.2 UMTS Radio Access Network 13 

9.1.3 UMTS Protocol Overview 13 

9.2 Requirements on the CBC-interfaces CBC-BSC and CBC-RNC 14 

9.2.1 Identification of a CBS message 14 

9.2.2 WRITE-REPLACE Request/Indication 15 

9.2.3 KILL Request/Indication 17 

9.2.4 REPORT Response/Confirm 17 

9.2.5 STATUS-LOAD-QUERY Request/Indication 17 

9.2.6 STATUS-LOAD-QUERY Response/Confirm 17 

9.2.7 STATUS-MESSAGE-QUERY Request/Indication 18 

9.2.8 STATUS-MESSAGE-QUERY Response/Confirm 18 

9.2.9 REJECT Response/Confirm 18 

9.2.10 RESTART-INDICATION Request/Indication 18 

9.2.11 RESET Request/Indication 19 

9.2.12 FAILURE-INDICATION Request/Indication 19 

9.2.13 SET-DRX Request/Indication 20 

9.2.14 SET-DRX- REPORT Response/Confirm 20 

9.3 Parameters 20 

9.3.1 Message-Identifier 20 

9.3.2 Old-Serial-Number 20 

9.3.3 New-Serial-Number 20 

9.3.4 Number-o^Pages 21 

9.3.5 Cell-List 21 

9.3.5.1 Cell-List sent from CBC to BSC/RNC 21 

9.3.5.2 Cell-List sent from BSC/RNC to CBC 21 

9.3.6 Channel Indicator 21 

9.3.7 Category 22 

9.3.8 Repetition-Period 22 

9.3.9 No-of-Broadcasts-Requested 22 

9.3.10 No-of-Broadcasts-Completed-List 23 

9.3.11 Cell-Identifier 23 

9.3.12 Schedule-Period 24 

9.3.13 Reserved-Slots 24 

9.3.14 Failure-List 24 

9.3.15 Radio-Resource-Loading-List 25 



ETSI 



(3G TS 23.041 version 3.1 .0 Release 1999) 4 eTSI TS 123 041 V3.1 .0 (2000-01) 

9.3.16 Cause 26 

9.3.17 Diagnostic 26 

9.3.18 Data Coding Scheme 26 

9.3.19 CBS-Message-Information-Page n 26 

9.3.20 CBS-Message-Information-Length n 27 

9.3.21 Recovery-Indication 27 

9.4 Message Format on the Radio Network - MS/UE Interface 27 

9.4.1 GSM 27 

9.4.1.1 General Description 27 

9.4.1.2 Message Parameter 27 

9.4.1.2.1 Serial Number 28 

9.4.1.2.2 Message Identifier 29 

9.4.1.2.3 Data Coding Scheme 30 

9.4.1.2.4 Page Parameter 30 

9.4.1.2.5 Content of Message 30 

9.4.2 UMTS 31 

9.5 CBS Compression 31 

10 CBS Index 32 

Annex A (informative): Protocols for interconnecting CBC and BSC 34 

Annex B (informative): Change Request History 35 

History 36 



ETSI 



(3G TS 23.041 version 3.1 .0 Release 1999) 5 eTSI TS 123 041 V3.1 .0 (2000-01) 



Foreword 



This Technical Specification has been produced by the 3 GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the specification; 
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1 Scope 

This Technical Specification describes the Cell Broadcast short message service (CBS) for GSM and UMTS. 

For GSM it defines the primitives over the Cell Broadcast Centre - Base Station System (CBC-BSS) interface and the 
message formats over the Base Station System - Mobile Station (BSS-MS) interface for Teleservice 23 as specified in 
3GTS 22.003 [2]. 

For UMTS it defines the interface requirements for the Cell Broadcast Center - UMTS Radio Network System (RNS) 
interface and the radio interface requirements for UMTS Radio Acces Networks to support CBS as specified in 3GPP 
22.003 [2]. 

1 .1 Normative references 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or non- 
specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[I] GSM 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and 
acronyms". 

[2] 3G TS 22.003: "Digital cellular telecommunication system (Phase 2+); Teleservices supported by 

a GSM PubHc Land Mobile Network (PLMN)". 

[3] 3G TS 23.038: "Digital cellular telecommunication system (Phase 2+) ; "Alphabets and language- 

specific information" . 

[4] 3G TS23.040: "Digital cellular telecommunication system (Phase 2+); Technical realization of the 

Short Message Service (SMS) Point to Point (PP)". 

[5] GSM 03.47: "Digital cellular telecommunication system (Phase 2+); Example protocol stacks for 

interconnecting Service Centre(s) (SC) and Mobile-services Switching Centre(s) (MSC)". 

[6] GSM 03.49: "Digital cellular telecommunication system (Phase 2+); Example protocol stacks for 

interconnecting Cell Broadcast Centre (CBC) and Mobile-services Switching Centre (MSC)". 

[7] GSM 04.12: "Digital cellular telecommunication system (Phase 2+); Short Message Service Cell 

Broadcast (SMSCB) support on the mobile radio interface". 

[8] GSM 05.02: "Digital cellular telecommunication system (Phase 2+); Multiplexing and multiple 

access on the radio path" . 

[9] 3G TS 27.005: "Digital cellular telecommunication system (Phase 2+); Use of Data Terminal 

Equipment - Data Circuit terminating Equipment (DTE - DCE) interface for Short Message 
Service (SMS) and Cell Broadcast Service (CBS)". 

[10] GSM 08.52: "Digital cellular telecommunication system (Phase 2+); Base Station Controller - 

Base Transceiver Station (BSC - BTS) interface Interface principles". 

[II] GSM 08.58: "Digital cellular telecommunication system (Phase 2+); Base Station Controller - 
Base Transceiver Station (BSC - BTS) interface Layer 3 specification". 
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[12] CCITT Recommendation X.210: "Open systems interconnection layer service definition 

conventions". 

[13] GSM 08.08 MSC-BSS Interface Layer 3 specification 

[14] 3G TS 23.042: " Compression algorithm for text messaging services". 

[15] GSM 03.48: "Digital cellular telecommunications system (Phase 2+); Security Mechanisms for the 

SIM appHcation toolkit; Stage 2" 

1 .2 Abbreviations 

Abbreviations used in this TS are Hsted in GSM 01.04 [1]. 



General description 



The CBS service is analogous to the Teletex service offered on television, in that like Teletex, it permits a number of 
unacknowledged general CBS messages to be broadcast to all receivers within a particular region. CBS messages are 
broadcast to defined geographical areas known as cell broadcast areas. These areas may comprise of one or more cells, 
or may comprise the entire PLMN. Individual CBS messages will be assigned their own geographical coverage areas by 
mutual agreement between the information provider and the PLMN operator. CBS messages may originate from a 
number of Cell Broadcast Entities (CBEs), which are connected to the Cell Broadcast Centre. CBS messages are then 
sent from the CBC to the cells, in accordance with the CBS's coverage requirements. 

A CBS page comprises of 82 octets, which, using the default character set, equates to 93 characters. Other Data Coding 
Schemes may also be used, as described in 3G TS 23.038 [3]. Up to 15 of these pages may be concatenated to form a 
CBS messagee. Each page of such CBS message will have the same message identifier (indicating the source of the 
message), and the same serial number. Using this information, the MS/UE is able to identify and ignore 
re-broadcasts of already received messages. 

CBS messages are broadcast cyclically by the cell at a frequency and for a duration agreed with the information 
provider. The frequency at which CBS messages are repeatedly transmitted will be dependent on the information that 
they contain; for example, it is likely that dynamic information such as road traffic information, will require more 
frequent transmission than weather information. The repetition period will also be affected by the desire for CBS 
messages to be received by high speed mobiles which rapidly traverse cells. All suitably equipped mobiles within the 
catchment area of the transmitting cell will be able to receive the CBS messages, provided that they are switched on and 
in the idle state. 

The meaning of 'Idle State' differs in GSM and UMTS. The concrete mapping between the meaning of 'Idle State' 
from a users perspective and the meaning in radio resource management and mobility management in UMTS is for 
further study. 

GSM only [CBS messages may be broadcast on two different cell broadcast channels, which are characterized by 
different QoS. A MS is always able to read the basic channel (see [8]). The reading of the extended channel may collide 
with other tasks of the MS. Therefore the probability of receiving a CBS message on the extended channel is smaller 
than on the basic channel. The reading of the extended channel for MSs is optional. The scheduling on the channels will 
be done independently.] 

To permit mobiles to selectively display only those CBS messages required by the MS/UE user, CBS messages are 
assigned a message class which categorises the type of information that they contain and the language (Data Coding 
Scheme) in which the CBS message has been compiled. Through the use of appropriate MMI, the user is then able to 
ignore message types that he does not wish to receive, e.g. advertising information or messages in an unfamiliar 
language. 



3 Network Architecture 

The chosen network architectures differs for GSM and UMTS. In chapter 3.1 the GSM network architecture is 
descripted, in chapter 3.2 the UMTS network architecture. 
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3.1 



GSM Network Architecture 



The basic network structure of CBS is depicted by figure 1. 



outside scope of GSIVI Specs. 



inside scope of GSIVI Specs. 
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Figure 1 

message transfer on link 1 is outside the scope of GSM Specifications; 

message transfer on Hnk 2 is described in subclause 9.1; 

message transfer on link 3 is described in GSM 08.58; 

message transfer on link 4 is described in GSM 04.12 and the timing of messages transferred on link 4 is 
described in GSM 05.02. 



3.2 



UMTS Network Architecture 



The basic network structure of CBS is depicted by figure 2 




Figure 2 

The basic network structure replaces the GSM BSS with the UTRAN containing the RNC and the Node B. The cell 
broadcast center (CBC) is part of the core network and connected to a routing node e.g. a 3G SGSN via the Be 
reference point. Thus the CBC can reach every RNC via the user plane of the lu interface. On the logical interface 
between the CBC and the RNC a mandatory protocol shall be defined. The other UTRAN related interfaces are 
described in the according UTRAN specifications based on the RAN 2 TR 25.925. Based on this architecture and the 
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current requirements for cell broadcast the core network elements like MSC, VLR, HLR etc are not involved for the 
service delivery. 



CBE Functionality 



The functionality of the CBE is outside of the scope of GSM and UMTS Specifications; however it is assumed that the 
CBE is responsible for all aspects of formatting CBS, including the splitting of a CBS message into a number of pages. 



CBC Functionality 



GSM only [As in GSM the CBC (and any originating point for CBS messages) is regarded as a node outside the PLMN, 
only the requirements placed upon the CBC by CBS functionality are specified by this specification.] 

In UMTS the CBC is regarded to be integrated as a node into the core network. 

The CBC may be connected to several BSCs/RNCs. The CBC may be connected to several CBEs. The CBC shall be 
responsible for the management of cell CBS messages including: 

- allocation of serial numbers; 

- modifying or deleting CBS messages held by the BSC/RNC; 

- initiating broadcast by sending fixed length CBS messages to a BSC/RNC for each language provided by the 
cell, and where necessary padding the pages to a length of 82 octets [see GSM 03.38]; 

- determining the set of cells to which a CBS message should be broadcast, and indicating within the Serial 
Number the geographical scope of each CBS message; 

- determining the time at which a CBS message should commence being broadcast; 

- determining the time at which a CBS message should cease being broadcast and subsequently instructing each 
BSC/RNC to cease broadcast of the CBS message; 

- determining the period at which broadcast of the CBS message should be repeated; 

- determining the cell broadcast channel, on which the CBS message should be broadcast. 

To work efficiently on the interfaces, the BSC/RNC - which is normally controlling more than one cell of a broadcast 
area - should be used as a concentrator as far as CBS message handling is concerned. Hence, the CBC should work on 
lists of cells when issuing CB related requests towards the BSC/RNC. 



BSC/RNC Functionality 



The BSC/RNC shall interface to only one CBC. A BSC may interface to several BTSs as indicated by GSM 08.52. A 
RNC may interface to several Node Bs. 

The BSC/RNC shall be responsible for: 



BSC 



RNC 



interpretation of commands from the CBC; 



storage of CBS messages; 



scheduling of CBS messages on the CBCH; 



Scheduling of CBS messages on the CBS 
related radio resources 



providing an indication to the CBC when the desired repetition period cannot be achieved; 



Providing to the CBC acknowledgement of successful execution of commands received from the 
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CBC; 


reporting to the CBC failure when a command received from the CBC is not understood or cannot 

be executed; 


routing CBS messages to the appropriate 
BTSs; 


Routing CBS messages 


transferring CBS information to each 
appropriate BTS via a sequence of 4 SMS 
BROADCAST REQUEST messages or 1 SMS 
BROADCAST COMMAND message (see 
GSM 08.58), indicating the channel which shall 
be used. 


The Node B has no functionality regarding 
CBS. This implies that CBS messages do not 
have to be transmitted explicitely to the Node 
Bs for further processing. 


optionally generating Schedule Messages, 
indicating the intended schedule of 
transmissions (see GSM 04.12); 


Generating Schedule Messages, indicating the 
intended schedule of transmissions (see 3G TS 

25.324) 


optionally receiving CBCH Load Indication 
messages and reacting by broadcasting a burst 
of scheduled CBS messages or by suspending 
the broadcast for a period indicated by BTS (see 
GSM 08.58); 


ffs 



To work efficiently on the interfaces, the BSC/RNC should forward CB related messages to the CBC using cell lists as 
far as applicable. 



BTS Functionality 



Only GSM [The BTS is responsible for conveying CBS information received via SMS BROADCAST REQUEST or 
SMS BROADCAST COMMAND messages over the radio path to the MS. 

- optionally generating CBCH Load Indication messages, indicating an underflow or overflow situation on the 
CBCH (see GSM 08.58).] 



8 MS/UE Functionality 



Only GSM [The MS is responsible for recombination of the blocks received via the radio path to reconstitute the CBS 
message.] 

The precise method of display of CBS messages is outside the scope of GSM Specifications, however it is assumed that 
an MS/UE will: 



MS 



discard sequences transferred via the radio 
path (see GSM 04.12) which do not consist of 
consecutive blocks; 



UE 



Discard corrupt CBS messages received on the 
radio interface 



have the ability to discard CBS information which is not in a suitable data coding scheme; 



have the ability to discard a CBS message which has a message identifier indicating that it is of 
subject matter which is not of interest to the MS; 



have the ability to ignore repeat broadcasts of CBS messages already received (message has not 
changed since it was last broadcast i.e. sequence number has not changed within the message's 

indicated geographical area); 
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have the abihty to transfer a CBS message to an external device, when supported ; 



optionally enter CBS DRX mode based 
upon received Schedule Messages (see 
GSM 04.12); 



Enter CBS DRX mode based upon received 
Schedule Messages (see 3G TS 25.324) 



optionally skip reception of the remaining 
block(s) of a CBS message which do(es) not 
contain cell broadcast information (see 
GSM 04.12); 



ffs. 



optionally read the extended channel 



Not appHcable for UMTS. 



enable the user to activate/deactivate CBS through MMI 



enable the user to maintain a "search list" and receive CBS messages with a Message Identifier in 
the list while discarding CBS messages with a Message Identifier not in the list 



allow the user to enter the Message Identifier via MMI only for the 1000 lowest codes 



be capable of receiving CBS messages consisting of up to 15 pages 



Protocols and Protocol Architecture 



9.1 Requirements on the Radio Access Network 
9.1 .1 GSM Radio Access Network 

Commands interpreted by the BSC will result in a sequence of 4 SMS BROADCAST REQUEST messages or 1 SMS 
BROADCAST COMMAND message being sent to a BTS, which in turn result in a sequence of 4 blocks each 22 octets 
long being transferred via the BTS-MS interface (see GSM 04.12). 

With the SMS BROADCAST REQUEST mode of operation, the 88 octet fixed length CBS page which is specified in 
Section 9.3 is split into four 22 octet blocks which are carried in SMS BROADCAST REQUEST messages as follows: 

octets 1-22 are transferred in the 1'^ SMS BROADCAST REQUEST 

with a sequence number (see GSM 04.12) indicating first block 

octets 23-44 are transferred in the 2"^ SMS BROADCAST REQUEST 

with a sequence number (see GSM 04.12) indicating second block 

octets 45-66 are transferred in the 3'^ SMS BROADCAST REQUEST 

with a sequence number (see GSM 04.12) indicating third block 

octets 67-88 are transferred in the 4'^ SMS BROADCAST REQUEST 

with a sequence number (see GSM 04.12) indicating fourth block. 

Figure 3 illustrates the protocol architecture and the scope of the various GSM Specifications for the SMS 
BROADCAST REQUEST mode of operation. 
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Figure 3 

With the SMS BROADCAST COMMAND mode of operation, the BSC sends to the BTS in one single message the \ 
octet fixed length CBS page. The BTS then splits the page into four 22 octet blocks, adds the sequence number (see 
GSM 04.12) and transmits the four resulting blocks on the air. 

Figure 4 illustrates the protocol architecture and the scope of the various GSM Specifications for the SMS 
BROADCAST COMMAND mode of operation. 
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9.1 .2 UMTS Radio Access Network 

ffs. 

9.1 .3 UMTS Protocol Overview 
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9.2 Requirements on the CBC-interfaces CBC-BSC and CBC- 
RNC 

The requirements are described by primitives. The term primitive is used to indicate "an abstract, implementation 
independent interaction between a service user and a service provider" (see CCITT X.210). For the CBC-BSC interface, 
the service provider would be the protocol interconnecting CBC and BSC. A Primitive may therefore be viewed as an 
abstract, implementation independent request/indication or response/confirm interaction between the service user (CBC 
or BSC) and the service provider (protocol). A set of primitives for use between the CBC and BSC is specified 
appropriate to the functionality assigned to the CBC and BSC in Sections 5 and 6. In order to allow future extensions to 
the primitives, where possible a primitive shall not be rejected because a parameter is not recognised; the recipient shall 
ignore the parameter in question and process the remainder of the primitive's parameters as usual. 

GSM only [No mandatory protocol between the CBC and the BSC is specified by GSM, this is a matter of agreement 
between CBC and PLMN operators. GSM 03.49 (see also annex A of this TS) provides example protocol stacks using 
the primitives defined as follows.] 

In UMTS the CBC is integrated into the Core Network.This implies a mandatory protocol between CBC and RNC. 

NOTE: In the following definitions, M indicates "mandatory parameter" and O indicates "optional parameter". 

9.2.1 Identification of a CBS message 

In GSM within a CBC-BSC interface, a CBS message is uniquely identified by the quartet (Message Identifier, Serial 
Number, Cell Identifier, Channel Indicator). 

In UMTS within the CBC-RNC interface, a CBS message is uniquely identified by the triplet (Message Identifier, 
Serial Number, Cell Identifier) 

This means that even when two CBS messages have the same semantic containts (for example the same weather 
forecast) but in different languages or coding schemes, they are considered as different and must therefore be identified 
by a different quartet. 

The Serial Number (Old-Serial-Number or New-Serial-Number) is managed cyclically and therefore this does not 
prevent the re-use of the same quartet for a different CBS message when the serial number have been incremented a 
sufficient number of times. How to manage the ambiguity is described subsequently. 

This unique identification of a CBS message across the CBC-BSC interface is used in all the primitives defined 
hereafter. This means that the quartet/triplet will be implicitly or explicitly present in every interface primitive which 
applies to a given CBS message. 

This unique quartet/triplet will be referred in the rest of the document as the « message reference ». 
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9.2.2 WRITE-REPLACE Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Message-Identifier 


9.3.1 


M 


Old-Serial-Number 


9.3.2 





New-Serial-Number 


9.3.3 


M 


Cell-List 


9.3.5.1 


M 


GSM only [Channel Indicator 


9.3.6 


0] 


Category 


9.3.7 





Repetition-Period 


9.3.8 


M 


No-of-Broadcasts-Requested 


9.3.9 


M 


Number-of-Pages 


9.3.4 


M 


Data Coding Scheme 


9.3.18 


M 


CBS-Message-Information-Page 1 


9.3.19 


M 


CBS-Message-Information-Length 1 


9.3.20 


M 


CBS-Message-Information-Page 2 


9.3.19 





CBS-Message-Information-Length 2 


9.3.20 





CBS-Message-Information-Page n 


9.3.19 





CBS-Message-Information-Length n 


9.3.20 






This primitive is sent by the CBC to the BSC/RNC. As this primitive can be used either to broadcast a new CBS 
message or replace a CBS message already broadcast, the CBC will use the presence and content of the Old-Serial- 
Number and New- Serial-Number fields in this primitive to instruct the BSC/RNC as follows :- 

- Old-Serial-Number not present/New-Serial-Number present 

This is a write request which will be interpreted by the BSC/RNC as an instruction to broadcast a new CBS 
message in all the cells of the Cell list. 

GSM only [The CBS message will be broadcasted on the channel derived by the Channel Indicator (see the 
section on parameters that describes the implicit value of the Channel Indicator when not present in the CBS 
message). ] 

The following table identifies the BSC/RNC 's behaviour: 



Success/Failure of write 
request 


BSC/RNC behaviour 


Success 


The BSC/RNC completes the following parameters to be returned in the 
Report PDU: 

• a '0' value is entered in the number of broadcasts completed Hst for 
the cell 

• no entry is made in the failure list for the cell 


Failure 


The BSC/RNC completes the following parameters to be returned in the 
Report PDU: 

• no entry is made in the number of broadcasts completed list for the 
cell 

• an entry is made in the failure list for the new CBS message 
identifying the failure cause for the cell 



The BSC/RNC will build as many message references as the number of cells in the list. These message 
references will be used in particular in the subsequent primitives. 

When a message reference is already known by the BSC/RNC for certain cells in the list (even if the Update 
field of the Serial-Number is different), the primitive will be rejected for those cells with the cause « message 
reference already used ». The list of cells where the message reference is not valid will be provided in the failure 
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list of the REPORT primitive. For these cells no entry will be made in the number of broadcasts completed 
parameter. 

Old-Serial-Number present/New-Serial-Number present 

This is a replace request which will be interpreted by the BSC/RNC as a kill request for the CBS message with 
the old serial number, followed by a write request for the CBS message with the new serial number. The 
handling of the new serial number in the write part of this request, is as described above in the write request 
where no Old-Serial-Number is supplied. These two kill and write requests are executed sequentially. If the kill 
request is unsuccessful, the BSC/RNC does not proceed to execute the write request. The kill request will stop 
broadcast of, and cause all information currently associated with the combination of message identifier, old serial 
number, GSM only [Channel Indicator] and the list of cells in the Cell list to be deleted from the cells in the 
BSC/RNC (i.e. for all cells provided in the Cell-List parameter). If the kill request is successful, the subsequent 
write request information conveyed in the primitive replaces the killed CBS message. The following table 
identifies the BSC/RNC s behaviour: 



Success/Failure of kill request 


BSC/RNC behaviour 


Success 


The BSC/RNC proceeds to execute the write request: 

• Write successful: the BSC/RNC completes the following parameters 
to be returned in the Report PDU: 

• an entry is made in the number of broadcasts completed list for 
the cell 

• no entry is made in the failure list for the cell 

• Write unsuccessful: the BSC/RNC completes the following 
parameters to be returned in the Report PDU: 

• an entry is made in the number of broadcasts completed list for 
the cell 

• an entry is made in the failure list for the new CBS message 
identifying the failure cause for the cell 


Failure 


The BSC/RNC does not proceed to execute the write request, and 
completes the following parameters to be returned in the Report PDU: 

• no entry is made in the number of completed broadcasts list 

• an entry is made for the old CBS message in the failure list 
identifying the failure cause for the cell 



All cells which should perform the broadcasting are mentioned in the Cell-List parameter. 

The broadcast of the referenced CBS message in the cells which are not mentioned in the Cell-List remains unaffected. 

If no category is present, the default category is interpreted by the BSC/RNC, see the parameter section. 

This primitive is responded by a REPORT or REJECT primitive. 

NOTE: GSM only [In the case of multipage CBS messages, the individual pages are considered as independent 
by the BSC scheduling algorithm.] 
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9.2.3 KILL Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Message-Identifier 


9.3.1 


M 


Old-Serial-Number 


9.3.2 


M 


Cell-List 


9.3.5.1 


M 


GSM only [Channel Indicator 


9.3.6 


0] 



This primitive is sent by the CBC to the BSC/RNC. The CBC will use this primitive to kill the message indicated by the 
combination of message identifier, serial number, GSM only [Channel Indicator] and the cells indicated in the Cell-List 
of this KILL request, i.e. the primitive will halt broadcast of the message in the indicated cells and remove any 
knowledge of the message from the BSC/RNC for these cells. The broadcast of the referenced message in the cells 
which are not mentioned in the Cell-List remains unaffected. This primitive is responded with a REPORT or REJECT 
primitive. 

9.2.4 REPORT Response/Confirm 



PARAMETER 


REFERENCE 


PRESENCE 


Message-Identifier 


9.3.1 


M 


Serial-Number 


9.3.2/9.3.3 


M 


GSM only [Channel Indicator 


9.3.6 


0] 


No-of-Broadcasts-Completed-List 


9.3.10 





Failure-List 


9.3.14 






This primitive will be sent by the BSC/RNC to the CBC in response to WRITE-REPLACE and KILL primitives. The 
Serial-Number field will contain the old serial number if this primitive is sent in response to a KILL primitive, and the 
new serial number if the primitive is sent in response to a WRITE-REPLACE primitive. 

The No-of-Broadcasts-Completed-List if present, may contain for each cell the number of broadcasts of the (replaced or 
killed) CB message with the old message reference sent to this particular cell for broadcast. The serial number 
information element in the case of a WRITE-REPLACE does not refer to the message for which the number of 
broadcasts completed information is supplied. The Failure-List if present, may contain those cells which were present in 
the related WRITE-REPLACE or KILL primitive and failed the requested operation. 

9.2.5 STATUS-LOAD-QUERY Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 
GSM only [Channel Indicator 


9.3.5.1 
9.3.6 


M 
0] 



This primitive is sent by the CBC to the BSC/RNC in order to obtain the current loading of the CBCH/UTRAN Radio 
Resource of particular cells referenced in the Cell-List parameter. This primitive is responded by a STATUS-LOAD- 
QUERY Response/Confirm or a REJECT primitive. 

9.2.6 STATUS-LOAD-QUERY Response/Confirm 



PARAMETER 


REFERENCE 


PRESENCE 


Radio-Resource-Loading-List 

Failure-List 
GSM only [Channel Indicator 


9.3.15 
9.3.14 
9.3.6 




0] 



This primitive will be sent by the BSC/RNC in response to the STATUS -LOAD-QUERY Request/Indication primitive. 

The Radio-Resource-Loading-List, if present, may contain each cell which successfully performed the requested 
operation and for each of these cells the CBCH loading/ UTRAN Radio Resource loadingof this particular cell. (Note 
that for cells with DRX the load caused by the schedule messages will be included in the load calculation). The Radio- 
ResourceLoading-List will not be present if all cells indicated in the related STATUS-LOAD-QUERY 
Request/Indication failed the requested operation. 
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The Failure-List, if present, may contain all cells for which the requested operation failed (e.g. because the cells CBCH 
is not available in a BTS). The STATUS -LOAD-QUERY Response/Confirm will not contain the 
Failure-List parameter if none of the cells in the Cell-List of the related STATUS -LOAD-QUERY Request failed the 
requested operation. 

9.2.7 STATUS-MESSAGE-QUERY Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Message-Identifier 


9.3.1 


M 


Old-Serial-Number 


9.3.2 


M 


Cell-List 


9.3.5.1 


M 


GSM only [Channel Indicator 


9.3.6 


0] 



This primitive is sent by the CBC to the BSC/RNC in order to obtain the current status of a CB -message for the cells 
referenced in the Cell-List parameter. This primitive is responded by the STATUS-MESSAGE-QUERY 
Response/Confirm or by a REJECT Response/Confirm. 

9.2.8 STATUS-MESSAGE-QUERY Response/Confirm 



PARAMETER 


REFERENCE 


PRESENCE 


Message-Identifier 


9.3.1 


M 


Old-Serial-Number 


9.3.2 


M 


No-of-Broadcasts-Completed-List 


9.3.10 





Failure-List 


9.3.14 





GSM only [Channel Indicator 


9.3.6 


0] 



This primitive will be sent by the BSC/RNC to the CBC in response to a STATUS-MESSAGE-QUERY 
Request/Indication primitive. 

The No-of-Broadcasts-Completed-List, if present, may contain each cell which successfully performed the requested 
operation and for each of these cells the number of times this CB message has been sent to this particular cell for 
broadcast (parameter Number-of-Broadcasts-Completed; this parameter is not included for the cell if the old message 
reference is not known to the BSC/RNC, and an entry is made in the failure list). The No-of-Broadcasts-Completed-List 
will not be present if all cells indicated in the related STATUS-MESSAGE-QUERY Request failed the requested 
operation. 

The Failure-List may contain all cells for which the requested operation failed (e.g. because the broadcast of the 
requested message was never requested before or because the cells CBCH is not available). The STATUS-MESSAGE- 
QUERY Response/Confirm will not contain the Failure-List parameter if none of the cells in the Cell-List of the related 
STATUS-MESSAGE-QUERY Request failed the requested operation. 

9.2.9 REJECT Response/Confirm 



PARAMETER 


REFERENCE 


PRESENCE 


Cause 


9.3.16 


M 


Diagnostic 


9.3.17 





Message-Identifier 


9.3.1 





Serial Number 


9.3.2 






This primitive is sent by the BSC/RNC to the CBC in response to any primitive which is not understood (e.g. invalid 
parameter or parameter value). 

9.2.10 RESTART-INDICATION Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 
Recovery Indication 


9.3.5.2 
9.3.20 


M 
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The RESTART-INDICATION Request is used by the BSC/RNC to indicate to the CBC a CB related restart situation in 
one or more of its cells (e.g. when an existing or a new cell becomes operational during normal BSC/RNC operation or 
when the BSC/RNC initiaHses). 

Any referenced cell are again in CB -operational state (have resumed CB operation). The parameter Recovery 
Indication, if present, indicates whether CB related data are lost for the cells referenced in the Cell-List and have to be 
re-loaded. If the Recovery Indication parameter is absent, the CBC shall interpret it as the Recovery Indication with the 
value data lost. 

The CBC upon receiving a RESTART INDICATION indication, marks the cell as operational again. It will usually 
generate WRITE-REPLACE requests for this cell, according to the actual CB message loading at the moment of the 
restart. 

Note that a RESTART INDICATION indication may be triggered from the CBC by a RESET Request. This allows to 
recover from situations, where a PDU occasionally may be lost. 

9.2.11 RESET Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 


9.3.5.1 


M 



The RESET Request is used by the CBC to force one or more cells of one BSC/RNC into CB-idle state. 

The RESET Request may also be used by the CBC to ask for the CB operational state of cells earlier indicated to have 
failed (polling CB operational state). 

If a BSC/RNCreceives a RESET Indication, the indicated cells enter idle state (same state as after "power on"). All CB 
related information concerning earlier CB messages in a referenced cell is lost. 

The BSC/RNC acknowledges the RESET Indication for each cell by an RESTART- or, if not adequate, by a 
FAILURE-INDICATION request. 

Of course, several responses may be combined using a cell list in the RESTART or FAILURE INDICATION. 

9.2.12 FAILURE-INDICATION Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 


9.3.5.2 


M 



The FAILURE-INDICATION Request is used by the BSC/RNC to indicate to the CBC a CB related problem situation 
in one or more of its cells. 

Any referenced cell enters CB -not-operational state. The status of the CBS messages is undefined until the Restart- 
Indication is sent. It remains in not-operational state until a RESTART-INDICATION request (see 9.1.10) indicates 
normal CB operation (again). 

The CBC upon receiving a FAILURE indication, marks this cell as failed. It will generally not generate further WRITE- 
REPLACE requests for this cell, up to the point, when the CBC is informed by a RESTART indication, that the cell has 
resumed CB operation. 

The BSC/RNC refuses further WRITE-REPLACE requests from the CBC with the cause "cell-broadcast-not- 
operational" when any referenced cell is in the CB -not-operational state. 

Note, that a Failure-Indication may be triggered by a RESET Request. This allows to recover from situations, where a 
PDU occasionally may be lost. 
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9.2.13 SET-DRX Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 


9.3.5.1 


M 


Schedule-Period 


9.3.12 





Reserved-Slots 


9.3.13 





GSM only [Channel Indicator 


9.3.6 


0] 



The SET-DRX Request is used by the CBC to set DRX specific parameters i.e. the schedule period and the number of 
slots reserved for high priority CBS messages, see GSM 04.12. At least one of the Schedule-Period or Reserved-Slots 
parameters must be present in the primitive. If this primitive is not supported, the BSC/RNC may use default values. 

If a BSC/RNC receives a SET-DRX Indication, the new DRX parameters will be taken into account starting from the 
next schedule period in each cell, see GSM 04.12. 

If a BSC/RNC receives a SET-DRX Indication, the new DRX parameters will be applied for all cells that do not handle 
any broadcast message (null loading). 

9.2.14 SET-DRX- REPORT Response/Confirm 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 

Failure-List 

GSM only [Channel Indicator 


9.3.5.2 
9.3.14 
9.3.6 




0] 



This primitive will be sent by the BSC/RNC to the CBC in response to a SET-DRX Request/Indication primitive. 

The Failure-List will contain those cells which were present in the Request message and which failed the requested 
operation. 

If the new schedule period parameters are not acceptable on a cell due to the load of the cell, the cause "bss-capacity- 
exceeded" is used in the Failure-list. 

9.3 Parameters 

9.3.1 Message-Identifier 

This parameter identifies source/type of a CBS message and is passed transparently from the CBC to the MSAJE. Its 
format is defined in 9.4.2.2. 

9.3.2 Old-Serial-Number 

This parameter equates to the parameter - Serial Number sent between the BSC/RNC and the MS/UE. Its format is 
defined in 9.4.2.1. 

This parameter enables a particular existing CBS message, from the source/type indicated by the message identifier, to 
be identified. 

9.3.3 New-Serial-Number 

This parameter equates to the parameter - Serial Number sent between the BSC/RNC and the MS/UE. Its format is 
defined in 9.4.2.1. 

This parameter enables CBS message change to be indicated since it is altered every time the CBS message is changed. 
The serial number identifies a particular CBS message, which may be several pages in length, from the source indicated 
by the message identifier. 
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9.3.4 Number-of-Pages 

This parameter enables the number of pages in the CBS message to be indicated. 

9.3.5 Cell-List 

The cell-Hst identifies a sequence of one or more cells to which the primitives apply. 

The following applies for GSM only: 

The cells in the list are described in GSM 08.08 and can be identified by the CBC or ESC in LAC and CI format or CI 
format only. 

In addition (see GSM 08.08) it is possible for the CBC to refer to all cells in a LAC or in a complete ESC. If supplied, 
the Cell-List parameter must refer to at least one cell. 

Given the above differences between cell identification in the two directions, a cell list sent from the CBC to the BSC 
has a different structure compared to a cell list sent from the BSC to the CBC. The different cell lists are described in 
sections 9.2.5.1 and 9.2.5.2. 

The following applies for UMTS only: 

ffs. 

9.3.5.1 Cell-List sent from CBC to BSC/RNC 

The CBC to BSC/RNC Cell-List contains a length parameter identifying the number of cell-identifications present in 
the list, a Cell-Id-Discriminator, which is common for all cell-identifications in the list, and a sequence of cell- 
identifications. 

Description of list elements: 



PARAMETER 


PRESENCE 


Length 

Cell-Id-Discriminator 

Cell-Identification 


M 
M 
M 



The following applies for GSM only: 

The Cell-Id-Discriminator is described in GSM 08.08 and has one of the following formats: 

- LAC and CI; 

- CI only; 

- all cells in the BSC belonging to a certain Location Area; 

- all cells in the BSC. 

The Cell-identification is repeated for each cell included in the list. The Cell-List must refer to at least one cell. 

The following applies for UMTS only: 

ffs. 

9.3.5.2 Cell-List sent from BSC/RNC to CBC 

The BSC/RNC to CBC Cell-List contains a sequence of cell-identifiers as defined in 9.3. IL The Cell-List must contain 
at least one cell-identifier as defined in 9.3.1L 

9.3.6 Channel Indicator 

The following applies for GSM only: 
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This parameter indicates the CB channel, which shall be used for broadcasting the data, 
basic channel; 

extended channel (supporting such a channel by the network or MSs is optional); 
If no channel indicator is present, it shall be interpreted as an indication to the basic channel. 

9.3.7 Category 

The following applies for GSM only: 

This indicates the category of the CBS message: 

High Priority: to be broadcast at the earliest opportunity in the reserved slots of the current schedule period (i.e. 
until the emission of the next schedule message), then according to the associated repetition period in the next 
schedule periods, in non reserved slots. 

Background: to be broadcast in the slots left free by CBS messages of category "High Priority" and "Normal", 
possibly shared with unscheduled schedule messages, see GSM 04.12. The repetition period defines the 
minimum broadcast requirement. 

Normal: to be broadcast according to the associated repetition period. 

If the category is omitted, the default category implied is "Normal" message. 

The following applies for UMTS only: 

ffs. 

9.3.8 Repetition-Period 

The following applies for GSM only: 

This indicates the period of time after which broadcast of the CBS message should be repeated. The minimum period 
with which a CBS message may be broadcast over the air interface is one 8x51 multiframe sequence which 
corresponds to a period of approximately 1.883 seconds. 

The value of "Repetition-Period" shall be in the range 1 to 1024 where each unit will represent one 8x51 multiframe 
sequence. 

In the event of a conflict where the BSS has more than one CBS message to send at the same time, the BSC shall decide 
the order of such CBS messages as an implementation matter. 

The following applies for UMTS only: 

ffs. 

9.3.9 No-of-Broadcasts-Requested 

This specifies the number of times the CBS message is to be broadcast. 

The following applies for GSM only: 

The parameter may take any value up to 65535 (this maximum allows the CBS message to be broadcast approximately 
every 1.883 seconds for more than 24 hours). If the parameter is set to then the CBS message will be broadcast 
indefinitely (i.e. until the BSC receives an appropriate Kill-Message Request/Indication primitive). 

The following applies for UMTS only: 

ffs. 
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9.3.10 No-of-Broadcasts-Completed-List 



This parameter is a list indicating the number of times that the CBS message (i.e. all pages of the CBS message) has 
been sent to each cell in the Cell-List for broadcast over the air interface. 

The following applies for GSM only: 

The cells in the list are described as per section 3.2.2.17 of GSM 08.08 and can be identified by LAC and CI or CI only. 

The following applies for UMTS only: 

ffs. 

Description of list elements: 



PARAMETER 


PRESENCE 


Cell Identifier 
No-of-Broadcasts-completed 
No-of-Broadcasts-Compl-lnfo 


M 
M 




The information above is repeated for the number of cells in the list. 

To each cell in the list the information element No-of-Broadcasts-completed is associated. This information element is 
related to the particular referenced cell in the list and contains the number of times a CBS message (i.e. all pages of a 
CBS message) has been sent to this cell for broadcast. The No-of-Broadcasts-completed information element 
represents the number of full broadcasts made of a CBS message, and that the CBS message is being (or had been) 
broadcast. 

The optional No-of-Broadcasts-Compl-Info information element may be supplied to indicate to the CBC one of the 
following cases: 

- overflow 

the count of the number of full broadcasts made of a CBS message has overflowed, and that the CBS message is 
being (or had been) broadcast. The actual number of broadcasts completed is greater than the value indicated in 
the No-of-Broadcasts-completed information element. 

unknown 

indicates that there is no information regarding the number of broadcasts completed in the BSC/RNC for the 
CBS message with the old serial number. The value indicated in the No-of-Broadcasts-completed information 
element is undefined in this case. 

The No-of-Broadcasts-Completed-List must contain at least one cell. 

9.3.11 Cell-Identifier 

The following applies for GSM only: 

The cell-identifier consists of a cell-id-discriminator and cell-identification pair. 

Description of list elements: 



PARAMETER 


PRESENCE 


Cell-ld-Discriminator 
Cell-Identification 


M 
M 



The Cell-Id-Discriminator is described inGSM 08.08 and has one of the following formats: 

- LAC and CI, 

- CI only. 
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The BSC can use the 'LAC and CI' format for a cell identifier in any response to the CBC. The BSC may also use the 
'CI only' format for a cell identifier when responding to a CBC primitive that had contained a cell with 'CI only' format 
for a cell identifier. 

The following applies for UMTS only: 

ffs. 

9.3.12 Schedule-Period 

The following applies for GSM only: 

Indicates the DRX schedule period length, see GSM 04.12. 

The following values should be coded: 

- no DRX; 

- length of the schedule period. 

If a schedule period length greater than 40 is used, the schedule message cannot be built entirely if more than 40 CBS 
messages have to be described in the period. Therefore, schedule period length shall be reduced to 40. 

The following applies for UMTS only: 

ffs. 

9.3.13 Reserved-Slots 

The following applies for GSM only: 

Indicates the number of slots marked as "free slots reading advised" in the schedule message and considered as reserved 
in a DRX schedule period for incoming high priority CBS messages, not scheduled in the current schedule period, see 
GSM 04.12. 

The spacing of the reserved slots is implementation dependent. 

Reserved slots shall receive a 40 value at maximum, taking into account the constraint for schedule period length. 

The following applies for UMTS only: 

ffs. 

9.3.14 Failure-List 

This identifies the list of cells for which the BSC/RNC could not complete the request. The failure cause for each cell is 
indicated. 

The following applies for GSM only: 

The cells in the list are described as per section 3.2.2.17 of GSM 08.08 and can be identified by LAC and CI or CI only. 

Description of list elements: 



PARAMETER 


PRESENCE 


Cell Identifier 

Cause 

Diagnostic 


M 
M 




The information above is repeated for the number of cells that failed. 

To each cell in the list the information elements Cause and, as an implementation option. Diagnostic are associated. 
These are related to the particular referenced cell in the list. 

The Failure-List must contain at least one cell. 
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The following applies for UMTS only: 
ffs. 

9.3.15 Radio-Resource-Loading-List 

The following applies for GSM only: 

A list of the predicted short term load of each cell in the list expressed as a percentage. The calculation of this 
percentage is an implementation matter. The load should reflect the number of used slots, and schedule messages and 
reserved slots must be taken into account. The cells in the list are described inGSM 08.08 and can be identified by LAC 
and CI or CI only. 

Description of list elements: 



PARAMETER 


PRESENCE 


Cell Identifier 
CBCH-Loading 


M 
M 



The information above is repeated for the number of cells in the list. 

To each cell in the list the information element CBCH-Loading is associated. This information element is related to the 
particular referenced cell in the list and contains the cells load. 

Note that for cells with DRX the load caused by the schedule messages will be included in the CBCH load. 

The CBCH-Loading-List must contain at least one cell. 

The following applies for UMTS only: 

ffs. 
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9.3.16 Cause 

Indicates reason why the BSC/RNC was not able to interpret or execute the received primitive. The causes are given in 
table 1. 

Table 1 



Cause 


Reason 


Parameter-not-recognized 


Sent when the recipient (CBC or BSC/RNC) was unable to 
act upon the primitive received due to an unrecognized 
parameter. A primitive should not be rejected only because a 
parameter is not recognized as this would prevent extensions 
to the service 


parameter-value-invalid 


Sent when a failure occurred due to the value of a parameter 
being invalid, e.g. out of range, or in Write-Replace, the 
parameter "no of pages" does not equal the number of pages 
received 


valid-CBS-message-not- identified 


Sent when the BSC/RNC does not recognize the CBS 
message reference 


cell-identity-not-valid 


Sent when the BSC/RNC does not recognize a cell Identity 


unrecognized-primitive 


Sent when the BSC/RNC did not recognize the primitive at all 


missing-mandatory-element 


Sent when a mandatory element is missing from the primitive 


bss-capacity-exceeded 


Sent when a write-replace fails because the BSC/RNC 
cannot meet the requested repetition period or when the set- 
drx parameters cannot be applied because of the cell loading 


GSM only [cell-memory-exceeded 


Sent when the local cell memory has been exceeded] 


bss-memory-exceeded 


Sent when the BSS/RNS is unable to store a CBS message 
as the BSS/RNS memory has been exceeded 


cell-broadcast-not-supported 


Sent when the CBCH/CBS related Radio Resource is not 
configured for a cell 


cell-broadcast-not-operational 


Sent when the CBCH/CBS related radio resource is not 
available because of error conditions or due to maintenance 
activities 


incompatible-DRX-parameter 


Sent when the DRX parameter(s) cannot be applied. 


GSM only [Extended-channel-not- 
supported 


Sent when a write-replace fails because the extended 
channel is not configured for a cell] 


message-reference already-used 


Sent when the recipient (BSC/RNC) was unable to act upon 
the write_replace received due to a previous write_replace 
received with the same message_reference. 


unspecified-error 


Sent when none of the above cause values apply 



9.3.17 Diagnostic 

Provides additional information associated with Cause parameter and may contain parameter which could not be 
interpreted/executed. 

9.3.18 Data Coding Scheme 

This parameter identifies the alphabet or coding employed for the message characters and message handling at the 
MS/UE and is passed transparently from the CBC to the MS/UE. This parameter is defined in 3G TS 23.038 [3]. 

9.3.19 CBS-Message-Information-Page n 

This parameter is of a fixed length of 82 octets and carries up to and including 82 octets of user information. Where the 
user information is less than 82 octets, the remaining octets must be filled with padding ( see 3G TS 23.038 [3] ). 

The content of a CBS -Message-Information-Page is passed transparently from the CBC to the MS/UE. 

In GSM the CBS -Message-Information-Page n becomes the 'Content of Message' parameter at the MS. 

In UMTS the CBS -Message-Information-Pages together with the associated CBS -Message-Information-Length 
parameter is broadcasted as a single unit over the radio inteface. 
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In the case where the user information is GSM 7 bit default alphabet encoded, the appropriate padding characters and 
bit-fill are added to the end of the user information to complete the CBC-Message-Information-Page ( see 3G TS23.038 
). 

In the case where the user information is 8 bit encoded, the appropriate padding octets are added to the end of the user 
information to complete the CBC-Message-Information-Page ( see 3G TS 23.038 ). 

9.3.20 CBS-Message-Information-Length n 

This parameter gives the number of octets of the CBS-Message-Information-Page n containing user information. The 
remaining octets of the CBS -Message-Information-Page n contain only padding information and are not included in this 
parameter. 

In the case where the user information is encoded using the GSM 7 bit default alphabet and the last character terminates 
at an octet boundary, this parameter indicates the number of octets of user information. In the case where the last 
character does not terminate at an octet boundary, this parameter indicates the number of octets up to the octet boundary 
immediately following the last GSM 7 bit default alphabet character of user information. 

In UMTS the CBS -Message-Information-Pages together with the associated CBS -Message-Information-Length 
parameter is broadcasted as a single unit over the radio inteface. 

9.3.21 Recovery-Indication 

Indicates whether the CBS related data was lost or is still available. 
The following values should be coded: 

- Data-available; 

- Data-lost. 

9.4 Message Format on the Radio Network - MS/UE Interface 
9.4.1 GSM 

The CBS messages which are transmitted by the BTS for the MS include the CBS Message (information for the user) 
and Schedule Message (schedule of CBS messages). 

The use and the formatting of the CBS messages, which contain information for the MS user, is described in this 
section. 

The Schedule Message is broadcast to support CBS DRX mode for Mobile Stations. The Schedule Message is helpful 
in minimizing battery usage for Cell Broadcast in the Mobile Station, because it allows the MS to ignore transmissions 
of CBS messages the customer is not interested in. The use and formatting of the Schedule Message is described in 
GSM 04.12. 



9.4.1.1 



General Description 



Each page of a CBS Message sent to the MS by the BTS is a fixed block of 88 octets as coded in GSM 04.12. This is 
sent on the channel allocated as CBCH by GSM 05.02. The 88 octets of the CBS Message are formatted as described in 
9.3.2. 



9.4.1.2 



Message Parameter 



Octet Number(s) 


Field 


1-2 


Serial Number 


3-4 


Message Identifier 
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Octet Number(s) 


Field 


5 


Data Coding Scheme 


6 


Page Parameter 


7-88 


Content of Message 



The octets in the above table are transmitted in order, starting with octet 1 . The bits within these octets are numbered 
to 7; bit is the low order bit and is transmitted first. 



9.4.1.2.1 



Serial Number 



This parameter is a 16-bit integer which identifies a particular CBS message (which may be one to fifteen pages in 
length) from the source and type indicated by the Message Identifier and is altered every time the CBS message with a 
given Message Identifier is changed. 

The two octets of the Serial Number field are divided into a 2-bit Geographical Scope (GS) indicator, a 10-bit Message 
Code and a 4-bit Update Number as shown below: 



Octet 1 


Octet 2 


7 


6 


5 


4 


3 


2 


1 





7 


6 


5 


4 


3 


2 


1 





GS 


Message Code 


Update Number 



The most significant bit of the update number is octet 2 bit 3. The most significant bit of the Message Code is octet 1 
bit 5 and the least significant bit of the Message Code is octet 2 bit 4. The most significant bit of the Geographical 
Scope is octet 1 bit 7. 

• Message Code 

The Message Code differentiates between CBS messages from the same source and type ( i.e. with the same 
Message Identifier). Message Codes are for allocation by PLMN operators. 

The Message Code identifies different message themes. For example, let the value for the Message Identifier be 
"Automotive Association" (= source), "Traffic Reports" (= type). Then "Crash on Al J5" could be one value for 
the message code, "Cow on A32 J4" could be another, and "Slow vehicle on M3 J3" yet another. 

• Geographical Scope 

The Geographical Scope (GS) indicates the geographical area over which the Message Code is unique, and the 
display mode. The CBS message is not necessarily broadcast by all cells within the geographical area. When two 
CBS messages are received with identical Serial Numbers/Message Identifiers in two different cells, the 
Geographical Scope may be used to determine if the CBS messages are indeed identical. 

In particular, the Geographical Scope tells the mobile if the CBS message is only cell wide (which means that 
any CBS message if received in the next cell is regarded as "new"), or PLMN wide (which means that the 
Message Code and/or Update Number must change in the next cell for the CBS message to be "new"), or 
Location Area wide (which means that a CBS message with the same Message Code and Update Number may or 
may not be "new" in the next cell according to whether the next cell is in the same Location Area as the current 
cell). 

The display mode indicates whether the CBS message is supposed to be on the display all the time 
("immediate") or only when the user wants to see it ("normal"). In either case, the CBS message will be 
displayed only if its Message Identifier is contained within the "search list" of the mobile (see 9.3.2). These 
display modes are indicative of intended use, without indicating a mandatory requirement or constraining the 
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detailed implementation by mobile manufacturers. The user may be able to select activation of these different 
modes. 

The coding of the Geographical Scope field is shown below: 



GS Code 


Display Mode 


Geographical Scope 


00 


Immediate 


Cell wide 


01 


Normal 


PLMN wide 


10 


Normal 


Location Area wide 


11 


Normal 


Cell wide 



Immediate = default direct display 

Normal = default display under user interaction 

NOTE: Code 00 is intended for use by the network operators for base station IDs. 

• Update Number 

The Update Number indicates a change of the message content of the same CBS message, i.e. the CBS 
message with the same Message Identifier, Geographical Scope, and Message Code. 

In other words, the Update Number will differentiate between older and newer versions of the same CBS 
message, within the indicated geographical area. A new CBS message may have Update Number 0000; however 
this number will increment by 1 for each update. Any Update Number eight or less higher (modulo 16) than the 
last received Update Number will be considered more recent, and shall be treated as a new CBS message, 
provided the mobile has not been switched off. 



9.4.1.2.2 



Message Identifier 



This parameter identifies the source and type of the CBS message. For example, "Automotive Association" (= source), " 
Traffic Reports" (= type) could correspond to one value. A number of CBS messages may originate from the same 
source and/or be of the same type. These will be distinguished by the Serial Number. The Message Identifier is coded in 
binary. 

The ME shall attempt to receive the CBS messages whose Message Identifiers are in the "search list". This "search list" 
shall contain the Message Identifiers stored in the EFcbmi, EFcbmid and EFcbmir files on the SIM (see GSM 11.11) and 
any Message Identifiers stored in the ME in a "list of CBS messages to be received". If the ME has restricted 
capabilities with respect to the number of Message Identifiers it can search for, the Message Identifiers stored in the 
SIM shall take priority over any stored in the ME. 

The use/application of the Message Identifier is shown in the following list, with octet 3 of the Message Identifier 
shown first, followed by octet 4. Thus "1234" (hex) represents octet 3 = 0001 0010 and octet 4 = 0011 0100. 

0000 - 03E7 (hex): To be allocated by PLMN operator associations. If a Message Identifier from this range is 
in the "search list", the ME shall attempt to receive such CBS message. 

This version of GSM 03.41 does not prohibit networks from using Message Identifiers in 
the range 0000 - 03E7 (hex) for Cell Broadcast Data Download to the SIM. 



03E8 (hex): 
03E9 (hex): 



LCS CBS Message Identifier for E-OTD Assistance Data message 
LCS CBS Message Identifier for GPS Assistance Data message 



03EA - OFFF (hex): Intended for standardization in future versions of GSM 03.41. These values shall not be 
transmitted by networks that are compliant to this version of GSM 03.41. If a Message 
Identifier from this range is in the "search list", the ME shall attempt to receive this CBS 
message. 



1000 - 107F (hex): 



Networks shall only use Message Identifiers from this range for Cell Broadcast Data 
Download in "clear" (i.e. unsecured) to the SIM (see GSM 1 1.14). If a message Identifier 
from this range is in the "search list", the ME shall attempt to receive this CBS message. 
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1080 - lOFF (hex): Networks shall only use Message Identifiers from this range for Cell Broadcast Data 

Download secured according to GSM 03.48 [15] to the SIM (see GSM 11.14). If a message 
Identifier from this range is in the "search list", the ME shall attempt to receive this CBS 
message. 

1100 - 9FFF (hex): intended for standardization in future versions of GSM 03.41. These values shall not be 
transmitted by networks that are compliant to this version of GSM 03.41. If a Message 
Identifier from this range is in the "search list", the ME shall attempt to receive this CBS 
message. 

AOOO - AFFF (hex): PLMN operator specific range. The type of information provided by PLMN operators using 
these Message Identifiers is not guaranteed to be the same across different PLMNs. If a 
Message Identifier from this range is in the "search list", the ME shall attempt to receive 
this CBS message. 

BOOO - FFFE (hex): intended as PLMN operator specific range in future versions of GSM 03.41. These values 
shall not be transmitted by networks that are compliant to this version of GSM 03.41. If a 
Message Identifier from this range is in the "search list", then the ME shall attempt to 
receive this CBS message. 

FFFF (hex): Reserved, and should not be used for new services, as this value is used on the SIM to 

indicate that no Message Identifier is stored in those two octets of the SIM. If this Message 
Identifier is in the "search list", the ME shall attempt to receive this CBS message. 

Generally, the MMI for entering these codes in the ME is left to the manufacturers' discretion. However, the 1000 
lowest codes shall be capable of being specified via their decimal representation i.e.: 

Octet 3 Octet 4 

0000 00000000 0000(decimal '000') 
0000 00000000 0001(decimal '001') 
0000 00000000 0010(decimal '002') 
0000 00000000 0011(decimal '003') 

0000 001 1 1 1 10 01 1 l(decimar999') 

9.4.1 .2.3 Data Coding Scheme 

This parameter indicates the intended handling of the CBS message at the MS, the alphabet/coding, and the language 
(when applicable). This is defined in 3G TS 23.038 [3]. 

When the SIM indicates one or more language preferences, the ME shall, by default, use the language(s) stored in the 
SIM (in the EFlp file) to set any language filter mechanisms provided by the ME. 

Optionally, the user can select the language(s) required by using an MMI, to determine whether a particular CBS 
message should be read and displayed. 

9.4.1 .2.4 Page Parameter 

This parameter is coded as two 4-bit fields. The first field (bits 0-3) indicates the binary value of the total number of 
pages in the CBS message and the second field (bits 4-7) indicates binary the page number within that sequence. The 
coding starts at 0001, with 0000 reserved. If a mobile receives the code 0000 in either the first field or the second field 
then it shall treat the CBS message exactly the same as a CBS message with page parameter 0001 0001 (i.e. a single 
page message). 

9.4.1 .2.5 Content of Message 

This parameter is a copy of the 'CBS-Message-Information-Page' as sent from the CBC to the BSC. 
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9.4.2 UMTS 

The CBS message format is described in 3G TS 25.324. The information elements Serial Number, Message Identifier 
and Data Coding Scheme are identical with those described for GSM in section 9.4.1 with respect to their structure and 
possible values. Any other differences to GSM, e.g. concerning the storage of the parameters on the USIM are for 
further study. 

9.5 CBS Compression 

Cell Broadcast messages may be compressed in accordance with the compression algorithm described in 3G TS 23.042 
[14]. 

The Data Coding Scheme parameter ( see 9.4.1.2.3 ) indicates whether or not a CBS Message is compressed. 

Compression and decompression may take place between a CBE and an MS or between a CBC and an MS. 

The compression applies only to user information sent between the CBC and the MS i.e. excludes any padding octets. 

Padding in the case of CBS compression is defined as an integral number of octets where each padding octet has a value 
FF hexadecimal. The insertion of padding for different scenarios is described in the paragraphs below. 

The compression footer ( see 3G TS 23.042 ) delimits the compressed user information bit stream at an octet boundary. 
The remainder of the 'CBS-Message-Information-Page' sent between the CBC and the BSC contains padding octets. 
The parameter 'CBS -Message-Information-Length' identifies the sum of the compressed octets, the compression header, 
and the compression footer ( see 3G TS 23.042 ), but not any padding. 

Compression may apply to a single 'CBS-Message-Information-Page' or across multiple 'CBS -Message-Information- 
Page's. 

In the case where Compression applies only to a single 'CBS-Message-Information-Page', the compression header shall 
be the first octet in that 'CBS-Message-Information-Page' and the compression footer shall immediately follow the 
compressed data stream. Any remaining octets after the compression footer shall contain padding up to and including 
the 82nd octet position. However, if the 82nd octet position contains the compression footer then there is no padding. 

In the case where compression applies across multiple 'CBS-Message-Information-Page's, the compression header shall 
be present only in the first octet position of the first 'CBS-Message-Information-Page'. The compression footer shall 
immediately follow the compressed data stream which will terminate within the last 'CBS-Message-Infirmation-Page'. 
Any remaining octets after the compression footer in the last 'CBS-Message-Information-Page' shall contain padding 
up to and including the 82nd octet position in the last 'CBS -Message-Information-Page'. However, if the 82nd octet 
position of the last 'CBS -Message-Information-Page' contains the compression footer then there is no padding. 

If it is required to convey different blocks of information which are to be treated by the MS as though they were 
physically independent pages rather than concatenated information then page break characters ( see 3G TS 23.038 ) 
may be inserted in the character stream prior to compression. The boundaries created by the page breaks will not 
normally align with the boundaries set by the page number parameters and so the page number parameters cannot be 
used to identify physically separate blocks of meaningful information. 

The decoding at the MS may be achieved by first locating the compression footer octet by working back from the 82nd 
octet in the last 'CBS-Message-Information-Page'. If padding is present, the MS must skip backwards over the padding 
until a non padding octet is found. By definition this octet must be the compression footer. The compression footer has 
a pre-defined bit combination which can never replicate a padding octet. If padding is not present in the 82nd octet 
position of the last 'CBS-Message-Information-Page', by definition the 82nd octet must be the compression footer. 

The compression footer defined in 3G TS 23.042 indicates whether there are any compressed data bits contained within 
the compression footer octet and, if not, how many compressed data bits are contained within the octet immediately 
preceding the compression footer. In order to prevent possible replication of the padding octet value in the compression 
footer octet value, the compression mechanism must ensure that when bits 0,1,2 in the compression footer are all ones 
all other bits in the compression footer octet are set to 
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10 



CBS Index 



An index structure is defined in this section. Index can be used by the operator to inform the end user about the type of 
CBS services available. Index has the structure of a tree. It can thus have sub parts which are called subindexes. A 
subindex can be embedded in the same index message as its parent ("embedded subindex") or it can physically be in a 
separate index message ("child subindex"). Every index message has a unique message identifier. They are always of 
the same type. Message Code 1010101010b shall be used to indicate this type. The root of the index structure shall be 
the index message with message identifier 0. Other index messages are linked to the root index with links. Definition of 
their message identifiers is left to the operator. 

A format ("enhanced format") for the index messages is described in this section. If this enhanced format is used in the 
index message the ms can present the index messages in its preferred format. 

Available CBS services are introduced in the index. This means that their message identifier and name are stated. 
Enhanced format includes a mechanism for separating a normal service introduction from embedded subindex 
introduction and child subindex introduction. The introduction of an embedded subindex specifies the "subindex-id" 
used for identifying services that belong to this subindex. Embedded subindexes can have subindexes embedded in 
them etc. If these "second level embedded subindexes" are introduced their subindex-id shall begin with the subindex-id 
of their parent. Same principle applies for subindexes in third, fourth etc. level. An example of an index structure is 
given in figure 6. 

Enhanced format includes a mechanism which allows the terminals to identify that the format of the index message is 
enhanced. The index-id -field and the above mentioned Message Code (1010101010b) constitute this mechanism: 

message-format = index-id index-element-intro+ 



index-id 

version 

number 



= "EI" version crlf 

= number+ 

^ M-^n l„2.. |..3„ |„4„ |„5„ |„^„ |„^„ |„g„ |„9„ |„Q„ 



index-element-intro = subindex-intro I service-intro 

subindex-intro = subindex-id " " subindex-name crlf 

= subindex-character+ 

= "a" l"b" I... l"z"l"A"l"B"l... I"Z" 

= name-character+ 

= <gsm03.38character excluding <CR> and <LF> > 

= <CR><LF> 

= subindex-id message-id delimiter service-name crlf. 

= number+ 

II II I II II 

= name-character+ 

Current version used is 1 . 

The use of "." as delimiter means that this service is a child subindex of the index structure. 

Delimiter " " is used in all other cases. 

Subindex-id shall not be used if the service introduced is in the first level of the index. Subindex-id: s are used in 
alphabetical order within an index message. They can be re-used in a child subindex. 



subindex-id 

subindex-character 

subindex-name 

name-character 

crlf 

service-intro 

message-id 

delimiter 

service-name 
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Index: 

(Msgld=0, Message Code = 1010101010b) 



Ell 

20 Hospitals 

34 Taxis 

a News 

a201 Int News 

a202 Nat News 

a203 Local News 

b Sports 

bSOl Football News 

b302 Hockey Results 

bSOS Basketball 

c Finance 

c401 Finance News 

ca Quotes NYSE 

ca412 NYSE industrial 

ca413 NYSE electronics 

ca414 NYSE blue 

c420. Quotes Tokyo 

d Weather 

d501 Local Weather 

d502 National Weather 

d503 Weather in Europe 

d504 Weather in the World 

900.Buy and Sell 



420 Quotes Tokyo: 

(Msgid = 420, Message Code = 1010101010b) 



Ell 

421 Tokyo Industrial 

422 Tokyo Finance 

423 Tokyo Blue 



900 Buy and Sell: 

(MsgId = 900, Message Code = 1010101010b) 



Ell 

901 Cars 

902 Bikes 

903 Boats 

a Home Electronics 
a911 Computers 
a912 Televisions 
a913 Radios 
920 Baby Clothes 
930 Magazines 
940 Books 



Figure 6 
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Annex A (informative): 

Protocols for interconnecting CBC and BSC 

The following is applicable for GSM only: 

No mandatory protocol between the Cell Broadcast Centre (CBC) and the Base Station Controller (BSC) is specified by 
GSM; this is a matter of agreement between CBC and PLMN operators. 

Some example protocols are provided in GSM 03.49 to assist CBC and PLMN operators. These are based on the 
following principles, which CBC and PLMN operators are recommended to follow even if they choose not to use one of 
the examples given in GSM 03.49. 

The protocol(s) between CBC and BSC should: 

a) provide the service defined for the CBC-BSC interface (see section 9); 

b) be based on protocols normally used for communication between switching and/or computer equipment; 

c) permit open interconnection - preferably using the OSI stack or equivalent (e.g. CCITT Number 7 Stack). 
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